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Article Information ABSTRACT 
Object Oriented Programming (OOP) paradigm is one of the programming styles that 


5 . emerged in response to the challenge of designing complex software. However, students 

Be cede ee find it hard to conceptualize objects when they were Ree accustomed to non Object Ori- 
Accepted: September 28, 2022 ented approach to programming. This paper hypothesizes that introducing Object Oriented 
OO) notations to students during the design phase will smoothen their transition to Object 

Published: September 30, 2022 Oriented Programming, To test the hypothesis, an experiment was conducted with the stu- 
dents of Al-Qalam University Katsina, Nigeria. The participating students were divided into 
two groups: (i) P/owchart group - representing the classical approach where flowcharts were 
used to design solutions. (ii) Actvity Diagram group - which represents the control group in 
which swim lane activity diagram, as Object Oriented notation, was introduced to them at 
the design phase. Both groups were later introduced to Class Responsibility Collaborators 
(CRC) cards as an Object Oriented implementation model. The students were tested, four 
different times, on how well they converted flowcharts or activity diagrams, as the case may 
be, into Class Responsibility Collaborators cards, and their performances were recorded. 
The results were analyzed using Repeated Measure Analysis of Variance (ANOVA). Unex- 
pectedly, the Flowchart group outperformed the Activity Diagram group but the results were 
not statistically significant. Similarly, there was no statistical difference between males’ and 
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females’ performances. 


INTRODUCTION 

Computer programming is an important skill across 
diverse fields and disciplines and even more so for 
students. As 
becoming more pervasive, the skill is one of the necessary 


Computing Science computers are 
requirements for continuous automation of the modern 
world as well as for the maintenance of the already 
automated systems. For computing based disciplines 
such as Computer Science and Software Engineering, 
programming courses ate taught at many levels - from 
the year of entry to the year of graduation. Despite the 
criticality of programming, acquiring the skills remains a 
challenge for many students(Mehmood ef a/., 2020). 
Although there are many reasons why students struggle 
with programming(Oroma ef a/., 2012; Qian ef al, 2017; 
Sheard e¢ a/., 2009) the following are the most relevant to 
this paper: 

i. The cognitive intensity that is required to learn the 
low-level details of programming. 

ii. Pedagogically, students have been literary dragged to 
it (the programming). 
For the low level details inhibiting the comprehension 
of programming as outlined in (i) above, over the years 
programming languages have evolved in which the level of 
abstraction has been raised. In the process of abstraction 
evolution, many programming styles /paradigms emerged. 
One of the emerged paradigms is the Object Oriented 
Programming (OOP) paradigm developed out of the 
desire to manage complexity and improve productivity 
in software development. It is a programming style that 
uses real world “objects” to design computer programs. 
OOP reduces the conceptual gap from the design space to 


the implementation space(Bucci e¢ a/., 2002; Evans, 2004) 
because the program is conceptualized as a collection of 
objects interacting to achieve a common goal(Hourani 
et al, 2019). Similarly, programs developed using OOP 
are easier to maintain because objects are easier to trace 
and update (G. Antoniol e¢ a/, 2001; Giulio Antoniol e¢ 
al., 2000; Bianchi e¢ a/, 2000). Further, OOP provides 
additional support for code reuse through inheritance and 
additional support for flexibility through polymorphism 
(Daly et a/., 1996). 

With OOP, professional software developers enjoy 
plethora of supports. For example, in testing, there 
exist unit testing frameworks (Daka & Fraser, 2014); in 
mapping objects to records in a relational database, there 
exist Object Relational Mapping frameworks (Torres et 
al., 2017); in design, there exists a collection of design 
patterns to solve similar recurring problems (Gamma 
et al., 1995); in source code organization, there exists 
guidelines and tool support for refactoring (Daughtry III 
& Kannampallil, 2005; Martin, 2018). 

As the saying goes that a picture may be worth 
more than a thousand words, it was envisaged that 
diagraming will improve comprehension of computer 
programming (Smetsers-Weeda & Smetsers, 2017) as 
pictorial representation simultaneously raises the level of 
abstraction from low to high and can be used to improve 
over teaching pedagogy. Consequently, diagrams were 
also introduced to represent the design of a solution that 
will be implemented as a computer program. One of the 
diagrams used for the design is Flowchart. Similarly, one 
of the diagrams used for OO design is Activity Diagram 
and some of the notations used in documenting OO 
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implementation are Class Responsibility Collaborators 
(CRC) models. We provide the details of the flowchart, 
the activity diagram, and the CRC in the Methodology section. 


Statement of the problem 

In the introductory computing courses, students are 
expected to learn how to design solutions to computing 
problems using notations such as flowcharts and then 
subsequently learn how to translate the flowchart into 
an algorithm to be implemented using the procedural 
style of programming. Later, and in subsequent courses, 
students are introduced to the OOP programming 
style as another implementation alternative. However, 
since students were already accustomed to procedural 
implementation and knew that the approach ‘works, they 
struggled to conceive objects when introduced later as a 
viable alternative(Borstler et a/, 2008; Cutts et a/., 2019; 
Kolling, 1999). Students already learned how to design 
solutions to problems without the concept of objects in 
the scheme of things and were later required to transition 
to Object Oriented implementation. One of the reasons 
for the struggle might be that they do not have a clue 
about objects in the design space but have been asked to 
reflect them in the implementation space, which requires 
unlearning the procedural style of implementation. 
Thus, this paper aims to compare the effect of learning 
flowcharts, as non OO design notation, and activity 
diagram (an OO based design notation) in transitioning 
to Object Oriented implementation. 


Research hypotheses 
Given the above, we envisage that the students may find 
the transition easier if OO-notations were also introduced 
to them while learning diagrammatic designs of solutions 
to computing problems (see Figure 1). As such, the paper 
hypothesized the following: 

¢ Hi: Introducing activity diagrams to students at 
the design stage will improve their ease of transition to 
Object Oriented implementation. 

¢ H2: there is a difference between males and females 
in transitioning to Object Oriented design (OOD). 
The rest of the paper is organized as follows: Section 2.0 
presents the research works related to this paper. Section 
3.0 explains the methodology adopted in this paper and 
begins with the clarification of the research constructs 
and ends with the detailed settings and execution of the 
study. Section 4.0 discusses the results obtained and 
highlights what could be threats to the validity of the 
research. Lastly, Section 5.0 concludes the paper. 


LITERATURE REVIEW 

Existing studies mostly focus on the performance of 
students in programming, generally, and not specifically 
on OOP. For instance, Olalekan ef a/, (Akinola & 
Nosiru, 2014) investigated the effect of students’ 
attitudes on ease of learning programming. They used 
students’ attitudes such as regular attendance to lectures 
and interest in programming as some of the research 


constructs. They found that regular attendance at lectures 
was the most important factor, followed by the students’ 
interest in programming, Other factors that were found 
to affect students’ performance in learning programming 
were positive perception about the programming and 
the lecturers’ attitudes toward the students. Similarly, 
Amnouychokanant ef a/, (Amnouychokanant ef al, 
2021) assessed the effect of students’ attitudes toward 
programming and its learning performance but with 
different sets of research constructs. Some of the research 
constructs used and found to be significant predictors of 
high-performance in programming were positive self- 
efficacy and creativity. 

There has beenacontinuous search for effective techniques 
to teach OOP. For instance, Loksa et al, (Loksa ef al, 
2016) proposed an approach aimed at teaching student 
problem solving skills. The approach put emphasis in 
creating an explicit mental model of the problem to be 
solved and depicting the coding as a mere translation of 
the mental model. Other techniques introduced include 
visualizing the progress in creating the solution as well 
as explicit support for promptings to reflect on their 
strategies to solve the problem. Similarly, (Bucci et a/, 
2002) reported how they worked in transitioning from 
the traditional imperative model to an Object Oriented 
model of learning programming for over ten years and 
concluded that teaching Object Oriented programming 
is not as simple or “natural” but difficult to convey to the 
students the advantages and methodologies associated 
with Object Oriented programming. 

Still on the search for effective pedagogies to teach 
OOP,(Anfurrutia e¢ a/., 2017)Implemented Kolb’s learning 
theory in visual programming environments in order to 
help students to become competent in Object Oriented 
programming. The authors analyzed the acceptance 
by the students as well as its effect on their motivation. 
Kolb’s learning theory entails four cycles that learners 
must undergo to acquite knowledge. The cycles are: (1) 
carrying out a specific activity to have concrete experience 
(it) reflecting on the experience from the carried out 
activity, (iii) conceptualizing the theoretical aspects of the 
activity, and (iv) applying the knowledge acquired in new 
scenatios or situations. The visual environments used 
were BlueJ and Greenfoot — another IDE for learning 
For the 
acceptance, students indicated that they would prefer 


and teaching based on simulations or games. 


using the tools even though females’ responses were 
more negative than males’. As for motivation, the results 
were not as good as the authors’ expected. However, the 
approach does not consider the problem analysis space. 

In another study on the pedagogical approach to teaching 
OOP, (Uysal, 2012) explored the effects of “objects-first’ 
and ‘objects-late’ methods of teaching Object Oriented 
Programming (OOP). The author experimented with 
two groups of students. The scope of the course was 
identical for the two groups but the structure of the 
contents differed in sequence. Both the participants in 
the two groups used Blue] IDE to eliminate the possible 
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effects of different instructional tools. The objects first 
learners used all visual functionalities of Blue] IDE while 
the objects late learners started with only the text-based 
interfaces of Blue] and were instructed to use the visual 
support only in the last lectures. The study found that the 
learners instructed with the objects-first method achieved 
higher learning outcomes. 

In a similar context of smooth transitioning from process 
engineering to process control engineering, (Vogel- 
Heuser ef a/, 2003) explored the benefit of modeling. 
From the experiment they had conducted with students, 
it turned out that the groups that previously modeled the 
process had advantages in describing the several process 
steps and structuring the Programmable Logic Controller 
(PLC) program. 

In another exploratory study, (Ivanovic et a/, 2015) 
investigated different aspects of teaching introductory 
courses on Object Oriented Programming at three 
(3) universities in different European countries. They 


Flowcharting 
(solution design using 
flowchart) 


Activity Diagraming 
(solution design using 
activity diagram) 


of transition to Object Oriented programming is assessed 


Figure 1: Conceptual model 


based on how well the class responsibility collaborators 
(CRC) model is produced. We expect gender to play a 
moderating role. 

To make the discussion in this section more concrete, 
we introduce a trivial problem of manual booking of 
an appointment with a dentist. In the manual process, a 
patient calls the dental clinic. The receptionist receives 
the call and guides the patients on the available slots. 
The patient selects one of the available slots, which 
he receptionist will reserve and informs the patient of 
he appointed schedule. For brevity, we assume that 


ection, we will discuss the background concepts with 


t 
t 
the patient has already registered with the clinic. In this 
s 
t 


he solutions to the stated problem using a flowchart, an 
activity diagram, and class responsibility collaborators 
(CRC) cards. 


Flowchart 

A flowchart is a diagrammatic representation of steps to 
solving a given problem. Although it can also be used 
for other things such as the analysis of the problem 
or documentation of a process, we use a flowchart in 


compared different aspects and experiences from Object 
Oriented programming courses that were taught in the 
three (3) institutions. They found that all the institutions 
use various forms of course delivery. This indicates that 
a generic strategy for teaching transition to OOP has 
not been found yet. However, in all three (3) institutions, 
technology-enhanced learning tools (TEL) played a 
central role in the OOP courses offered. In particular, 
Blue] - an integrated development environment (IDE) 
for learning OOP with Java language designed for 
educational purposes- was found to be used in all three 
institutions. 


METHODOLOGY 

Figure 1 represents the conceptual model of this paper. 
In the Figure, flowcharting represents the art of non 
Object Oriented problem solving using flowcharts 
while Activity diagraming represents the art of Object 
Oriented problem solving using activity diagrams. Ease 


Ease of transitioning to OOP (CRC Modelling) 


this paper in the context of representing a solution to 
a computing problem. A flowchart is an approximate 
representation of an algorithm to solve a specific 
computing problem. 

A flowchart can be used to teach problem solving without 
getting deep into the low-level details of complete 
syntaxes of a programming language so that learning can 
be focused on the problem solving aspect. Flowchart- 
based programming environments are also used to entice 
students to programming with the big picture of the 
intended solution in their minds(Chen & Mortis, 2005; 
Smetsers-Weeda & Smetsers, 2017). 

The flowchart in Figure 2 represents the design of an 
automated system to solve the problem of manually 
booking of an appointment with a dentist as outlined 
above. As shown in the figure, after starting the system, it 
displays the list of available slots for patients to request an 
appointment with a dentist. The patient would then select 
a slot and request its booking. The system then checks 
to confirm if the slot has not been reserved for other 
patients since, due to time lag, another patient might have 
requested and booked the selected slot. If the slot has 
already been taken, the system returns the patient to the 
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list of available slots otherwise the system will reserve the 
slot and send a notification email to the patient. Lastly, 
the booking information shall be displayed to the patient. 


available slots 
slot selection and booking request 


yes 
reserve slot and email patient 
meeting info 


Is the slot still available? 


Activity Diagram 
The activity diagram is one of the behavioural 
diagrams of Unified Modelling Language (UML). 


Legend 


O 


| processing symbol 


decision symbol 


start/stop symbol 


input/output symbol 


control flow symbol 


Figure 2: Flowchart illustration of a dentist booking system 


It is similar to the flowchart as it can be used to 
diagrammatically represent a series of actions or flow of 
control to solve a given problem. Similarly, it can be used 
for other things such as modelling business processes or 
behavioural descriptions of a use case diagram(Jeyaraj & 
Sauter, 2014; Khaled AbdElazim ef a/., 2020). 

Swim lane activity is an activity diagram that is used to 
show which system actor is responsible for what, in 
addition to the representation of the series of actions or 
flow of control to solve the problem. ‘Thus, the presence 
of objects as well as their high level responsibilities can 
be captured explicitly as system actors on the diagram. 
Swim lane activity diagrams are also powerful models 


System 


display available meeting slots 


[selected slot no longes|available] 


Patient 


[selected still 


reserve slot and email patient 


select one of the available slots 


reservation info 


a 


in model-driven engineering (MDA) in the sense that 
they could also be transformed into other models or 
executable (Zhang ef a/., 2012). The diagram may as well 
be recovered from Object Oriented source codes through 
reverse engineering(Martinez ef a/., 2011). 

Figure 3 is an activity diagram that represents the same 
solution depicted in Figure 2 as Flowchart. It is a swim 
lane activity diagram because the responsibilities are 
indicated under the System and Patient as the main actors. 


Class Responsibility Collaboration (CRC) 
Class Responsibilities Collaborators (CRC) was invented 
by Ward Cuningham and Kent Beck(Beck & Cunningham, 


Activity Activity Action node 


Control Flow 


Start node 


——_ 
> Decision merge node 
[Guard] Guard condition 


Finish node 


@ 


Figure 3: Swim lane activity diagram representing the design of a dentist booking system 


1989; Cunningham & Beck, 1986) as an approach to 
discovering and documenting objects in OO design. CRC 
was initially designed to simplify learning OOP but has 
also been used in professional software development 
such as Agile’s eXtreme Programming (XP)(Beck, 1999). 


A class represents a template from which similar objects 
are created, responsibility is something that a class knows 
or does, and a collaborator is another class that a class 
interacts with to fulfill its responsibilities. CRC card is 
a 3x5 index card and is partitioned into three: the first 
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and the topmost portion is a row in which the name of 
the class being considered is represented; the second and 
the leftmost portion, represent the responsibilities of that 
class; the third portion represents the collaborators that 
the class will need to complete its responsibilities. Figure 
4 presents the major CRC cards derivable from the swim 
lane activity diagram of Figure 3. 


Thus, as shown in Figure 4, five initial classes were 
identified as Patient, DentalBookingManager, Slot, 
BookedSlot, and Dentist. 

CRC can be regarded as an implementation model as 
the major activity for OO implementation is identifying 
classes, their responsibilities, and collaborators without 
resorting to implementation details. We could have used 


Patient Dental Booking Manager 
Id Dental Booking Manager Available slots Slot 
name Booked slots BookedSlot 
previous appointments Process booking request _| Patient 
future appointments Process cancellation Dentist 
request for reservation request 
request for cancellation 
BookedSlot 
Scheduled slot Slot 
Patient reserved for Patient 
Slot Dentist 
Slot id Dental Booking Manager id 
Scheduled dentist Dentist Name 
Scheduled time Rank 


Figure 4: CRC cards for objects implementing the dentist booking system in OOP 


a class model instead but a study had found that students 
are more keen with CRC than the class diagram (Gray 
et al., 2003). 
implemented as an OOP program with relative ease. 


Further, a correctly designed CRC can be 


Study Setting 

An experiment was conducted with year one students 
of Al-Qalam University Katsina, Nigeria drew using a 
sample of convenience as only volunteers were recruited. 
The population of the study was Computer Science 
and Software Engineering students enrolled in the 
Introduction to Problem Solving course (module). The 
study recruited two groups of students: the Flowchart 
group consists of seventeen (17) students enrolled to 
study B.Sc. The Computer Science and Activity Diagram 
group comprises seventeen (17) students enrolled to 
study B.Sc. Software Engineering. All the students had 
taken Introduction to Computer Science in the previous 
semester. The distinct groups of the students were 
briefed about the motive of the experiment. 

The students in the Flowchart group were taught flowcharts 
for a week and then preceded to learn Class Responsibility 
Collaboration (CRC) for another week. Students were 
then taught how to translate flowcharts to CRC cards for 
two weeks. Hence, the first group transitioned to Object 
Oriented implementation from procedural notations. 
The students in the Activity Diagram group were taught 
the swim-lane activity diagram for a week and then 
preceded to learn class responsibility collaboration (CRC) 
for another week. Students were then taught how to 
translate the swim lane activity diagram to CRC cards for 
two weeks. Therefore, the second group transitioned to 
Object Oriented implementation from Object Oriented 
design. A final-year undergraduate student taught both 


groups as part of her final year project. 

The students were tested four (4) times within one week, 
each with a new problem. The reason for repeating the 
tests was to reduce the random noise and uncover the 
actual performance. In all the tests, the performances 
of the students were measured in terms of how well 
they translated the flowchart or activity diagram, as the 
case may be, to class responsibility collaborators (CRC) 
catds. That is, students in the different groups were 
asked the same question but with different notations to 
transitioning to CRC. 

The experiment was treated as a 2 X 4 factorial design. 
Group was a between-subject factor with two levels 
(Flowchart vs Activity Diagram). The within-subject 
factor was the test which has four levels (testl, test2, 
test3, and test4). Data collected from the experiment 
were students’ age, gender, and the scores of the tests. 


RESULTS 

In the two groups, there were a total of twenty-one 
(21) male students and thirteen (13) female students. 
However, five (5) female and three (3) male performance 
records were removed before the analysis because they 
were absent in some of the tests. Therefore, assessments 
of only twenty-four (24) students were analysed. Since 
the study was repeated four (4) times, we still had 96 data 
points that were subjected to the analysis. 

The scores for the individual students ranged from 50 to 
100 with the overall (grand) average score as 82.01. The 
means scores of the four different tests range from 78.85 
to 84.39 but the difference was not statistically significant 
Fd, 3)=1.424, P=0.242. However, the means scores 
for all the four tests were significantly higher than the 
expected mean score of 50 to 55 obtained from historical 
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scores of computing courses (t1(25)=14.61, p=0.000; 
t2(25)=15.22, p=0.000; t3(25)=17.87, p=0.000; t4(25) 
=13.86, p=0.000). 

In the first, second, and fourth tests, the means for the 
males were 85.61, 80.83, and 83.06 respectively. The means 
for females were 81.63, 74.38, and 80.63 respectively. 
Thus, the means for the male were higher. In contrast, in 
the third test, the means for females were slightly higher 
which was 83.13 against males’ 82.22. However, there 
was no significant interaction between gender and the 
performance F(1,3) = 0.531, p=0.663. 

In the first, second, and third tests, the mean for the 
Flowchart group were 86.0, 84.55, and 85.46 respectively, 
while for the Activity Diagram group the means were 83.2, 
74.67, and 80.33 respectively. Thus, the means for the 
Flowchart group were higher than the expected outcome. 
In the fourth test, the means were comparably very close: 
for the Flowchart Group 82.27 while for the Activity Diagram 
group 82.33. 

In addition to the quantitative results analyzed above, 
the second author also profiled students’ mistakes. In the 
Flowchart group, students found it difficult to distinguish 
between input/output and process symbol as both were 
used interchangeably. They were also not bothered to put 
the stop symbols at the end of the flowchart. Lastly, they 
use directional arrows inappropriately. For the Activity 
Diagram group, Stadents struggle with specifying the 
different actors in the different columns of the diagram. 
They mistook the end node and the end node. Lastly, they 
often place a process in a column it does not belong to. 
Nonetheless, the students in both groups were making 
similar mistakes in the CRC such as skipping some of 
the responsibilities, interchanging the position of the 
responsibilities and collaborators, and not writing the 
class name. 


DISCUSSION 

It might be observed that the average score of the 
participants students was remarkably high considering 
the rate of failure in computer programming and problem 
solving related ourse(Omeh & Olelewe, 2021); It might be 
the case that only high-performing students volunteered 
to participate in the study. Similar to the studies in 
(Amnouychokanant ef a/, 2021; Omeh & Olelewe, 
2021), no significant interaction between gender and the 
performance. Thus, we reject the hypothesis that there is 
a difference between males and females in transitioning to 
Object Oriented design (OOD). The findings contrast 
with the results obtained in(Anfurrutia e¢ a/., 2017) where 
males’ and females’ preferences differed significantly. 
Similar to the results obtained in (VVilner et a/, 2007), 
there was no significant interaction between the different 
groups and the performance (F(1, 3) = 1.160, p=0.331). 
Consequently, we reject the hypothesis that introducing 
activity diagrams to students at the design stage will 
improve their ease of transition to Object Oriented 
implementation. It likely that the sample used in the 
study was not large enough. Thus, further study should 


be conducted with large and (semi)randomised samples. 


Threat to Validity 

It may be argued that the activity diagram may not be 
the right notation to test the ease of transitioning from 
procedural style as previous studies mostly used Integrated 
Development Environments (IDEs) (Anfurrutia ef 
al, 2017; Ivanovie et a/, 2015; Uysal, 2012). However, 
using IDEs assumed that students already know how 
to design solutions before their implementation using a 
specific programming environment. Our study focused 
on problem-solving without the cumbersome aspect 
of learning syntaxes of any programming language. 
In addition, modeling using, diagrammatic notation, 
helps in bringing out the big picture of the intended 
solution(Vogel-Heuser ef a/., 2003). 

There was a chance of sampling error as the students’ 
average scores were significantly high. Nevertheless, since 
the individual scores ranged from 50 to 100 and there 
was a total of 96 data points, any variations between the 
groups that were not down to chance should have been 
detected. However, further study with large and (semi) 
randomised samples may give better insight. Similarly, 
the results may not be generalizable as the participated 
students were mainly novices. Nonetheless, different 
backgrounds do not necessarily matter(VVilner et a/., 


2007). 


CONCLUSION 

When learners were already accustomed to the procedural 
implementation style, they may struggle to conceive objects 
in object oriented programming despite the advantage 
of the Object Oriented style over the procedural style. 
This paper conceived that introducing Object Oriented 
modeling at the solution design phase may help ease the 
transition to Object Oriented programming. Thus, the 
paper experimented to test the effect of object oriented 


modeling in easing the transition to Object Oriented 
style. The results show that introducing the Object 
Oriented modeling will not achieve that desired effect as 
expected. The paper suggests further studies with large 
and randomise sample. 
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